To a large extent computers today employ a somewhat antiquated boot sequence, or variations of it, for loading their operating systems. As well known, the system BIOS is an essential set of routines in a computer for providing an interface between the operating system (OS) and the hardware, and is responsible for initializing the computer once it is powered on. System BIOS typically is stored on a single firmware chip residing on the computer's motherboard, and BIOSes may require periodic updating to keep pace with new peripheral technologies. If the BIOS is stored in a read only memory (ROM BIOS) updating it necessitates replacing the firmware itself. In current systems, however, BIOSes are stored on flash memory chips (e.g. EPROMs and EEPROMs) to allow them to be upgraded via software. Peripheral devices may also have their own BIOS. One such peripheral device, the video card (or video adapter), is guaranteed to have such firmware code stored on ROM or a flash chip. Thus, for example, FIG. 1 diagrammatically represents a video card 10 having video firmware 12 provided with a header 14 and firmware code—in this case the video BIOS code 16. When the firmware 12 is accessed, a jump instruction 18 directs control to the beginning of the video BIOS code 16 for execution, all as known in the art.
A typical boot sequence 20 is summarized in FIG. 2. Actual boot sequences may vary by hardware manufactures, peripherals associated with the computer, peripheral BIOSes, etc. Thus, FIG. 2 generalizes the boot sequence for explanatory purposes. When power is supplied to the computer 22 pre-programmed instructions direct the processor to location FFFF0h at the end of the system memory, which contains a “jump” instruction informing the processor of the actual location of the system BIOS boot program. From there the system BIOS is loaded 24 from ROM into system memory for execution.
During execution, the system maps interrupts service routines for basic interrupts 26. Also during execution, system BIOS performs the power-on self test (POST) 28 and probes 210 for peripheral devices on its internal bus to map any additional interrupts and memory to these components. By convention, to enable an interface for the user, the system BIOS looks 212 to the first video card listed on its device mapping, and particularly the video BIOS, in order to initiate a console for the user. The video BIOS is loaded into memory 214 as a shadow copy at location C000h; or it can be mapped to allow for direct access. Control is then passed to the video BIOS 216 which is executed to initialize the video card. Modern systems at this point display information on the monitor about the video card. Control is then returned to the system BIOS 218 to ascertain if there are any additional peripheral BIOSes to execute. Thereafter, system BIOS proceeds to perform other routine functions 220 as needed, for example, memory tests, system inventory, configuration of plug-n-play devices, etc.
System BIOS then begins to search for a bootable drive (hard disk drive, floppy disk drive, CD-ROM drive, etc.), the ordering of which can be determined by a boot sequence setting. Typically the bootable drive is one of the hard drives of the computer system. The primary interface the BIOS has for accessing a hard disk is the software interrupt known as interrupt (INT) 13h. INT 13h has been the standard for many years but is being replaced with a newer interface called INT 13h extensions to accommodate larger hard disk memories while remaining compatible with older systems. Upon being called 222 INT 13h directs system BIOS to the master boot record (MBR) 224 on the bootable hard disk so that the OS can be loaded. The MBR is sometimes also referred to as the master boot sector or the boot sector, and is always located at cylinder 0, head 0, sector 1 (the first sector of the bootable disk).
A typically MBR has various parts. One part stores all of (or at least part of) a boot loader (or boot code)—a small program that loads the OS into the computer's memory when the system is booted and starts the OS. A typical boot loader, for example, may be 446 bytes long and stored within address range 000000-0001 bd. The MBR also contains a master partitions table that is 64 bytes long at address range 0001 be-0001 fd for describing the partitions contained on the hard disk, and a boot code signature of 55aa which is typically 2 bytes and stored at 0001 fe-0001 ff. This is essentially a flag to let the system know if there is actual a bootloader associated with the MBR.
Once system BIOS reads the MBR and copies it into memory 226, typically at location 0000:7C00, it jumps to this location to execute the boot loader. Depending on the order of installation an OS specific boot loader can add entries to the existing bootloader. For example, NTLDR is the boot loader for Windows including its later versions 2000/XP/Server2003. NTLDR can also load a non NT-based operating system given the appropriate boot sector in a file. NTLDR requires, at a minimum, the following two files to be on the active partition—NTLDR, which contains the main boot loader itself, and boot.ini, which contains configuration options for a boot menu. To load an NT-based OS, ntdetect.com must also be present. The equivalent of it in Linux is LILO/bootsect.s. In any event, once the boot loader is executed, it in turn loads the OS 228 from the hard drive into RAM. Boot sequence 20 then ends at 230.
Some practiced in the art refer to the entire sequence discussed above as the boot sequence while others confine that term only to the actual part which loads the OS, while referring to the preceding steps generically as POST. For purpose of this disclosure, the former characterization is adopted for distinction only and not for limitation. Those practiced in art will be aware that specifications are available for both BIOSes and boot loaders. For example, BIOS boot specification version 1.01 (May 9, 1995) is a emerging standard co-developed by Phoenix, Compaq, Intel and Microsoft. Also, for users of free operating systems such as Linux, Free BSD, Net BSD, MACH and VSTA, “The Multiboot Specification” is available. Each of these are hereby incorporated by reference as background information.
Since, by convention, system BIOSes read the MBR to locate code for loading the OS, this legacy predictability renders computers susceptible to exploitation by boot sector viruses. Such viruses, as with other types, can be malicious or simply annoying, but are always of concern. In the past, boot viruses were commonly written to the boot sectors of floppy disks when these were in widespread use. For example, when one neglected to remove the floppy disk from the drive when powering down the computer, subsequent powering on would lead to the system BIOS reading the boot sector program. Under normal conditions this would load the conventional OS, but could instead be tailored to execute an infected program. Once infected, the boot virus replicated itself onto subsequent floppies used on the machine. Perhaps the most well known boot virus for infecting computers in such a manner was known as the “Michaelangelo” virus. Currently, a major class of viruses referred to as “boot sector infectors” target the vulnerable boot areas of the hard disk. Some infect the code in the MBR while others infect code in the volume boot sector(s). By infecting such areas, a virus is assured to be loaded into memory each time the machine is booted from the infected area.
It is maintained that inadequate measures have been implemented thus far date to insulate computers against these types of attacks. For various reasons preventive measures are desired. For instance, by ensuring that systems will never boot or run anything not specifically configured or intended (i.e. customary), one can be confident that operating systems like KNOPPIX and other live-on-CD or live-on-USB distributions are not bootable. As such, system stability is maintained. Moreover, even if the malicious loading of a boot virus into the MBR cannot be prevented through suitable security measures, deviation from this traditional boot sequence to an alternate boot path would render a virus dormant since it would not be loaded, in turn facilitating subsequent detection repair of the infected area(s). Thus, improved measures are desired to provide enhanced security in relation to the booting sequence.
The foregoing discussion of the related art and its related limitations is intended to be illustrative and not exclusive. Other limitations may become apparent to those practiced in the art upon a reading of the specification and a study of the drawings.